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Abstract 
The iSCSI protocol provides a way for hosts to access SCSI devices 
over an IP network. This document defines the use of the Service 
Location Protocol (SLP) by iSCSI hosts, devices, and management 
services, along with the SLP service type templates that describe the 


services they provide. 
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Les 


Introduction 


iSCSI [RFC3720] is a protocol used to transport SCSI [SAM2] commands, 
data, and status across an IP network. This protocol is connection- 
oriented and is currently defined over TCP. iSCSI uses a client- 
server relationship. The client end of the connection is an 
initiator, and it sends SCSI commands; the server end of the 
connection is called a target, and it receives and executes the 
commands. 


There are several methods an iSCSI initiator can use to find the 
targets to which it should connect. Two of these methods can be 
accomplished without the use of SLP: 


- Each target and its address can be statically configured on the 
initiator. 


- Each address providing targets can be configured on the initiator; 
iSCSI provides a mechanism by which the initiator can query the 
address for a list of targets. 


The above methods are further defined in "iSCSI Naming and Discovery 
Requirements" [RFC3721]. 


Each of the above methods requires a small amount of configuration to 
be done on each initiator. The ability to discover targets and name 
services without having to configure initiators is a desirable 
feature. The Service Location Protocol (SLP) [RFC2608] is an IETF 
standards track protocol providing several features that will 
simplify locating iSCSI services. This document describes how SLP 
can be used in iSCSI environments to discover targets, addresses 
providing targets, and storage management servers. 


Notation Conventions 
In this document, the key words "MUST", "MUST NOT", "REQUIRED", 


"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" are to be interpreted as described in [RFC2119]. 
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3. Terminology 


iSCSI and SLPv2 April 2005 


Here are some definitions that may aid readers who are unfamiliar 


with SLP, SCSI, or iSCSI. 
reproduced from [RFC2608] 


[RFC3105]. 


User Agent (UA) 


Service Agent (SA) 


Directory Agent (DA) 


Scope 


Service Advertisement 


Initiator 


Target 


iSCSI Name 


iSCSI Client 


Bakke & Hufferd 


Some of these definitions have been 


and "Finding an RSIP Server with SLP" 


A process working on the client’s behalf 
to establish contact with some service. 
The UA retrieves service information from 
the Service Agents or Directory Agents. 


A process working on behalf of one or more 
services to advertise the services and 
their capabilities. 


A process that collects service 
advertisements. There can only be one DA 
present per given host. 


A named set of services, typically making 
up a logical administrative group. 


A URL, attributes, and a lifetime 
(indicating how long the advertisement is 
valid) providing service access 
information and capabilities description 
for a particular service. 


A logical entity, typically within a host, 
that sends SCSI commands to targets to be 
executed. An initiator is usually present 
in the form of a device driver. 


A logical entity, typically within a 
storage controller or gateway that 
receives SCSI commands from an initiator 
and executes them. A target includes one 
or more Logical Units (LUs); each LU is a 
SCSI device, such as a disk or tape drive. 


A UTF-8 character string that serves as a 
unique identifier for iSCSI initiators and 
targets. Its format and usage is further 
defined in [RFC3721]. 


A logical entity, typically a host that 
includes at least one iSCSI Initiator. 
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iSCSI Server A logical entity, typically a storage 
controller or gateway that includes at 
least one iSCSI Target. 


Storage Management Server An addressable entity that provides 
management services that benefit an iSCSI 
environment. "Storage management server" 
is used as a generic term and does not 
indicate a specific protocol or service. 


4. Using SLP for iSCSI Service Discovery 


Two entities are involved in iSCSI discovery. The end result is that 
an iSCSI initiator (e.g., a host) discovers iSCSI targets, usually 
provided by storage controllers or gateways. 


iSCSI targets are registered with SLP as a set of service URLS, one 
for each address on which the target may be accessed. Initiators 
discover these targets by using SLP service requests. Targets that 
do not directly support SLP or that are under the control of a 
management service may be registered by a proxy service agent as part 
of the software providing this service. 


iSCSI entities may also use SLP to discover higher-level management 
services when these are needed. 


This section first describes the use of SLP for discovery of targets 
by iSCSI initiators, it then describes the use of SLP to discover 
storage management servers. 


This document assumes that SLPv2 will be used for discovering iSCSI- 
related services; no attempt is made to include support for SLPvl. 


4.1. Discovering iSCSI Targets with SLP 


The following diagram shows the relationship among iSCSI clients, 
servers, initiators, and targets. An iSCSI client includes at least 
one iSCSI initiator, and an SLP user agent (UA). An iSCSI server 
includes at least one iSCSI target an SLP service agent (SA). Some 
entities, such as extended copy engines, include both initiators and 
targets. These include both an SA, for its targets to be discovered, 
and a UA, for its initiator(s) to discover other targets. 
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4--------------------------------- + 
| iSCSI Client | 
4+----------- + 
| iSCSI | 
| | initiator | | 
| | "myhost" | | 
| +----------- + | 
ERE je 
| iSCSI Driver UA | 
4-------------------------- 4+------ + 
| TCP/UDP/IP | 
4+---------------- 4+---------------- + 
| Interface 1 | Interface 2 | 
4+---------------- 4+---------------- + 
4------------ + 4+------------ + 
| SLP DA | | | | SLP DA | 
| (optional) A IP Networks ar (optional) | 
4+------------ + 4+------------ + 
| | 
4----------------- 4----------------- 
| Interface 1 | Interface 2 | 
| 192.0.2.131 | 192.0.2.3 | 
4----------------- 4+----------------- + 
| TCP/UDP/IP | 
4+--------------------------- 4+------- + 
| iSCSI Driver SA 
+--------------------------- 4+------- 
| | 
| +-------- + $-------- + $--------- + | 
| | iscsı | | iscsı | | iscsı | | 
| | target | | target | | target | | 
| "one" | | "two" | | "three" | 
4+-------- + 4+-------- + 4+--------- + 
| iSCSI Server | 
4----------------------------------- + 


In the above drawing, the iSCSI server has three iSCSI targets that 
the client could discover, named "one", "two" and "three". The iSCSI 
client has an iSCSI initiator with the name "myhost". The iSCSI 
client may use the initiator name in its SLP Service Requests as a 
filter to discover only targets that are configured to accept iSCSI 
connections from "myhost". 


Each iSCSI target and initiator has a unique name, called an iSCSI 


Name. This identifier is the same regardless of the network path 
(through adapter cards, networks, and interfaces on the storage 
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device) over which the target is discovered and accessed. For this 

example, the iSCSI names "one", "two", and "three" are used for the 

targets; the initiator uses the name "myhost". An actual iSCSI name 
would incorporate more structure, including a naming authority, and 

is not described here. 


Each of the iSCSI targets in the drawing can appear at two addresses, 
since two network interfaces are present. Each target would have two 
service URLs, unless a single service URL included a DNS host name 
mapping to both addresses. 


An iSCSI target URL consists of its fully qualified host name or IP 
address, the TCP port on which it is listening, and its iSCSI name. 
An iSCSI server must register each of its individual targets at each 
of its network addresses. 


The iSCSI server constructs a service advertisement of the type 
"service:iscsi:target" for each of the service URLs it wishes to 
register. The advertisement contains a lifetime, along with other 
attributes that are defined in the service template. 


If the server in the above drawing is listening at TCP port 3260 for 
both network addresses, the service URLs registered would be 


- 192.0.2.131:3260/one 

- 192.0.2.131:3260/two 

- 192.0.2.131:3260/three 
- 192.0.2.3:3260/one 

- 192.0.2.3:3260/two 

- 192.0.2.3:3260/three 


The remainder of the discovery procedure is identical to that used by 
any client/server pair implementing SLP: 


1. If an SLP DA is found, the SA contacts the DA and registers the 
service advertisement. Whether or not one or more SLPv2 DAs are 
discovered, the SA maintains the advertisement itself and answers 
multicast UA queries directly. 


2. When the iSCSI initiator requires contact information for an 
iSCSI target, the UA either contacts the DA by using unicast or 
the SA by using multicast. If a UA is configured with the 
address of the SA, it may avoid multicast and may contact an SA 
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by using unicast. The UA includes a query based on the 
attributes to indicate the characteristics of the target(s) it 
requires. 

3. Once the UA has the host name or address of the iSCSI server, as 


well as the port number and iSCSI Target Name, it can begin the 
normal iSCSI login to the target. 


As information contained in the iSCSI target template may exceed 
common network datagram sizes, the SLP implementation for both UAs 
and SAs supporting this template MUST implement SLP over TCP. 


4.1.1. Finding Targets Based on Initiator Credentials 
To be allowed access to an iSCSI target, an initiator must be 


authenticated. The initiator may be required by the target to 
produce one or more of the following credentials: 


An iSCSI Initiator Name 


An IP address 


A CHAP, SRP, or Kerberos credential 
- Any combination of the above 


Most iSCSI targets allow access to only one or two initiators. In 
the ideal discovery scenario, an initiator would send an SLP request 
and receive responses ONLY for targets to which the initiator is 
guaranteed a successful login. To achieve this goal, the iSCSI 
target template contains the following attributes, each of which 
allows a list of values: 


1. auth-name: This attribute contains the list of initiator names 
allowed to access this target, or the value "any", indicating 
that no specific initiator name is required. 


2. auth-addr: This attribute contains the list of host names 
and/or IP addresses that will be allowed access to this target, 
or the value "any", indicating that no specific address or 
host name is required. If a large number of addresses is to 
be allowed (perhaps a subnet), this attribute may contain the 
value "any". 
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3. auth-cred: This attribute contains a list of "method/identifier" 
credentials that will be allowed access to the target, provided 
they can produce the correct password or other verifier during 
the login process. If no specific credentials are required, the 
value "any" is used. 


The list of valid method strings for auth-cred are defined in 
[RFC3720], section 11.1, "AuthMethod". The identifier used after the 
"/" is defined by the specific AuthMethod, also in [RFC3720]. 
Examples showing initiator searches based on auth-xxxx attributes are 
shown in the target-specific template section below. 


Also note that the auth-xxxx attributes are considered security 


policy information. If these attributes are distributed, IPsec MUST 
be implemented as specified in the Security Implementation section 
below. 


4.1.2. Supporting Access by Multiple Identities to the Same Target 


If a target is to allow access to multiple host identities, more than 
one combination of auth-xxxx attributes will have to be allowed. In 

some of these cases, it is not possible to express the entire set of 

valid combinations of auth-xxxx attributes within a single registered 
service URL. For example, if a target can be addressed by 


auth-name=myhostl AND auth-cred=CHAP/userl (identityl) 
OR 
auth-name-myhost2 AND auth-cred=CHAP/user2 (identity2) 


the above cannot be specified in a single registered service URL, 
since (auth-name=myhostl, auth-name=myhost2, auth-cred=CHAP/userl, 
auth-cred=CHAP/user2) would allow either auth-name to be used with 
either auth-cred. This necessitates the ability to register a target 
and address under more than one service URL; one for (identityl) and 
one for (identity2). 


Because service URLs must be unique, (identityl) and (identity2) must 
each be registered under a unique service URL. For systems that 
support the configuration of multiple identities to access a target, 
the service URL must contain an additional, opaque string defining 
the identity. This appears after the iSCSI name in the URL string 


and is separated by a "/". Each registered (target-address, target- 
name, initiator-identity) tuple can then register a set of auth-xxxx 
attributes. 
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4.1.3. Using SLP in a Non-multicast Environment 


In some networks, the use of multicast for discovery purposes is 
either unavailable or not allowed. These include public or service- 
provider networks that are placed between an iSCSI client anda 
server. These are probably most common between two iSCSI gateways, 
one at a storage service provider site, and one at a customer site. 


In these networks, an initiator may allow the addresses of one or 
more SAs to be configured instead of or in addition to its DA 
configuration. The initiator would then make unicast SLP service 
requests directly to these SAs, without the use of multicast to 
discover them first. 


This functionality is well within the scope of the current SLP 
protocol. The main consequence for implementors is that an initiator 
configured to make direct unicast requests to an SA will have to add 
this to the SLP API, if it is following the service location API 
defined in [RFC2614]. 


4.2. Discovering Storage Management Services with SLP 


Storage management servers can be built to manage and control access 
to targets in a variety of ways. They can provide extended services 
beyond discovery, which could include storage allocation and 
management. None of these services are defined here; the intent of 
this document is to allow these services to be discovered by both 
clients and servers, in addition to the target discovery already 
being performed. 


The following drawing shows an iSCSI client, an iSCSI server, anda 
storage management server. To simplify the drawing, the second IP 
network is not shown but is assumed to exist. The storage management 
server would use its own protocol (smsp) to provide capabilities to 
iSCSI clients and servers; these clients and servers can both use SLP 
to discover the storage management server. 
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4+----------- + 
| | iSCSI | | 
| | initiator | | 
| +----------—- + | 
| | 
4--------------- 4+------ 4+----+ 4+------------ + 
| iSCSI Driver | smsp | UA | | SLP DA | 
$--------------- +-----—- +----+ | | 
| TCP/UDP/IP | | (optional) | 
4--------------- 4+------ +--—--+ 4+------------ + 


+--------------- +----------- + +--------------------- + 
| TCP/UDP/IP | | TCP/UDP/IP | 
+--------------- +------ +----+ $--------------------- + 
| iSCSI Driver | smsp | UA | | SA | smsp | 
EE Fans +----+ EE SE EE EEE + 
| | | | 
| +-------- + +-------- + | | storage mgmt server | 
| | iscsı | | iscsı | | | | 
| | target | | target | | Sr sea A a + 

| 1 | 2 

+-------- E + 


Note the difference between the storage management server model and 
the previously defined target discovery model. When target discovery 
was used, the iSCSI Server implemented an SA, to be discovered by the 
initiator’s UA. In the storage management server model, the iSCSI 
clients and servers both implement UAs, and the management server 
implements the SA. 


A storage management server’s URL contains the domain name or IP 
address and TCP or UDP port number. No other information is 
required. 


The storage management server constructs a service advertisement of 
the type "service:iscsi:sms" for each of the addresses at which it 

appears. The advertisement contains the URL and a lifetime, along 

with other attributes that are defined in the service template. 
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The remainder of the discovery procedure is identical to that used to 
discover iSCSI targets, except that both initiators and targets would 
normally be "clients" of the storage management service. 


Targets that support a storage management service implement a UA in 
addition to the SA. A target may alternatively just implement the UA 
and allow the storage management service to advertise its targets 
appropriately by providing an SA and registering the appropriate 
service:iscsi:target registrations on the target’s behalf: The target 
device would not have to advertise its own targets. This has no 
impact on the initiator. 


This allows the initiators’ discovery of targets to be completely 
interoperable regardless of which storage management service is used, 
or whether one is used at all, or whether the target registrations 
are provided directly by the target or by the management service. 


4.3. Internationalization Considerations 
SLP allows internationalized strings to be registered and retrieved. 
Attributes in the template that are not marked with an ’L’ (literal) 
will be registered in a localized manner. An "en" (English) 


localization MUST be registered, and others MAY be registered. 


Attributes that include non-ASCII characters will be encoded by using 
UTF-8, as discussed in [RFC3722] and [RFC3491]. 


5. iSCSI SLP Templates 


Three templates are provided: an iSCSI target template, a management 
service template, and an abstract template to encapsulate the two. 


5.1. The iSCSI Abstract Service Type Template 


This template defines the abstract service "service:iscsi". It is 
used as a top-level service to encapsulate all other iSCSI-related 
services. 


Name of submitter: Mark Bakke 
Language of service template: en 
Security Considerations: See section 6. 


Template Text: 


template-type=iscsi 
template-version=1.0 


template-description= 
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This is an abstract service type. The purpose of the iscsi 
service type is to encompass all of the services used to support 
the iSCSI protocol. 


template-url-syntax= 
url-path= ; Depends on the concrete service type. 


5.2. The iSCSI Target Concrete Service Type Template 


This template defines the service "Service:iscsi:target". An entity 
containing iSCSI targets that wishes them discovered via SLP would 
register each of them, with each of their addresses, as this service 


type. 


Initiators (and perhaps management services) wishing to discover 
targets in this way will generally use one of the following queries: 


1. Find a specific target, given its iSCSI Target Name: 


Service: service:iscsi:target 
Scope: initiator-scope-list 
Query: (iscsi-name=iqn.2001-04.com.example:sn.456) 


2. Find all of the iSCSI Target Names that may allow access to a 
given initiator: 


Service: service:iscsi:target 
Scope: initiator-scope-list 
Query: (auth-name=iqn.1998-03.com.example:hostid.045A7B) 


3. Find all of the iSCSI Target Names that may allow access to 
any initiator: 


Service: service:iscsi:target 
Scope: initiator-scope-list 
Query: (auth-name=any) 


4. Find all of the iSCSI Target Names that may allow access to 
this initiator, or that will allow access to any initiator: 


Service: service:iscsi:target 

Scope: initiator-scope-list 

Query: & (auth-name=iqn.1998-03.com.example:hostid.045A7B) 
(auth-name=any) 
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5. Find all of the iSCSI Target Names that may allow access to 
a given CHAP user name: 


Service: service:iscsi:target 
Scope: initiator-scope-list 
Query: (auth-cred=chap/my-user-name) 


6. Find all of the iSCSI Target Names that may allow access to a 
given initiator that supports two IP addresses, a CHAP credential 
and SRP credential, and an initiator name: 


Service: service:iscsi:target 

Scope: initiator-scope-list 

Query: & (| (auth-name=ign.com.example:host47) (auth-name=any) 

| (auth-addr=192.0.2.3) (auth-addr=192.0.2.131) (auth-addr=any) 

| (auth-cred=chap/foo) (auth-cred=srp/my-user-name) 
(auth-cred=any) ) 


7. Find the iSCSI Target Names from which the given initiator is 
allowed to boot: 


Service: service:iscsi:target 
Scope: initiator-scope-list 
Query: (boot-list=iqn.1998-03.com.example:hostid.045A7B) 


8. In addition, a management service may wish to discover all 
targets: 


Service: service:iscsi:target 
Scope: management-server-scope-list 
Query: <empty-string> 


More details on booting from an iSCSI target are defined in [BOOT]. 


Name of submitter: Mark Bakke 
Language of service template: en 
Security Considerations: see section 6. 


Template Text: 

ETTE EE EG template begins here--*=====--5-sshans=snss= 
template-type=iscsi:target 

template-version=1.0 


template-description= 
This is a concrete service type. The iscsi:target service type is 


used to register individual target addresses to be discovered 
by others. UAs will generally search for these by including one of 
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- the iSCSI target name 
— iSCSI initiator identifiers (iSCSI name, credential, IP address) 
- the service URL 


template-url-syntax= 
= hostport "/" iscsi-name [ "/" identity ] 


url-path 
hostport 
host 
hostname 
alphanum 
domainlabel 
toplabel 
hostnumber 
ipv4-number 
ipv6-addr 
ipv6-number 


1s32 


h16 

port 
iscsi-name 
identity 
iscsi-char 


escaped 


r 


= host [ ":" port ] 
hostname / hostnumber ; DNS name or IP address 
*( domainlabel "." ) toplabel 
ALPHA / DIGIT 
alphanum / alphanum *[alphanum / "-"] alphanum 
ALPHA / ALPHA *[ alphanum / "-" ] alphanum 


ipv4-number / ipv6-addr ; IPv4 or IPv6 address 
1*3DIGIT 3("." 1*3DIGIT) 
"[" ipv6-number "]" 


6( h16 ":" ) 1832 
/ Wes Bl ELG 11) 41532 
/ I hl16.1J "se" 4¢( ALO Me" ) 1832 
/ E *1( h16 ":" ) h16 ] Tiet 3(h16 ":" ) 1832 
7 [— *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) 1832 
/ PE *3¢ his Ter 3) hi6 ] se" RLG TT 1s32 
/ E *4( h16 ":" ) h16 ] "::" 1s32 
/ [ *5( h16 ":" yj h16 J "::" h16 
/ [ *6( h16 ":" ) h16 ] Tc" 
( h16 ":" h16 ) / ipv4-number 


; least-significant 32 bits of ipv6 address 
1*4HEXDIG 

1*DIGIT 

iscsi-char ; iSCSI target name 

iscsi-char ; optional identity string 
ALPHA / DIGIT / escaped / ":" / "—" fo" 

; Intended to allow UTF-8 encoded strings 
1*("\" HEXDIG HEXDIG) 


; The iscsi-name part of the URL is required and must be the iSCSI 
; name of the target being registered. 


; A device representing multiple targets must individually 

; register each target/address combination with SLP. 

; The identity part of the URL is optional, and is used to 

; indicate an identity that is allowed to access this target. 


; Example (split into two lines for clarity): 
; service:iscsi:target://192.0.2.3:3260/ 


iqn.2001-04.com.example:sn.45678 


; IPv6 addresses are also supported; they use the notation 


Bakke & Hufferd 
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; specified above and in [RFC3513], section 2.2 


iscsi-name = string 
# The iSCSI Name of this target. 
# This must match the iscsi-name in the url-path. 


portal-group = integer 

# The iSCSI portal group tag for this address. Addresses sharing 
# the same iscsi-name and portal-group tag can be used within the 
# same iSCSI session. Portal groups are described in [RFC3720]. 


transports = string M L 
tcp 
# This is a list of transport protocols that the registered 
# entity supports. iSCSI is currently supported over TCP, 
# but it is anticipated that it could be supported over other 
# transports, such as SCTP, in the future. 


mgmt-entity = string O 

# The fully qualified domain name, or IP address in dotted-decimal 
# notation, of the management interface of the entity containing 

# this target. 

# 


alias = string O 
# The alias string contains a descriptive name of the target. 


auth-name = string M X 

# A list of iSCSI Initiator Names that can access this target. 
# Normal iSCSI names will be 80 characters or less; max length 
# is 255. 

# Normally, only one or a few values will be in the list. 

# Using the equivalence search on this will evaluate to "true" 
# if any one of the items in this list matches the query. 

# If this list contains the default name "any", any initiator 

# is allowed to access this target, provided it matches 

# the other auth-xxx attributes. 

# 

# 

# 

# 


This attribute contains security policy information. If this 
attribute is distributed via an Attribute Reply message, 
IPsec MUST be implemented. 


auth-addr = string M X 

# A list of initiator IP addresses (or host names) which will 

# be allowed access to this target. If this list contains the 
# default name "any", any IP address is allowed access to this 
# target, provided it matches the other auth-xxx attributes. 
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# 

# This attribute contains security policy information. If this 
# attribute is distributed via an Attribute Reply message, 

# IPsec MUST be implemented. 


auth-cred = string M X 

# A list of credentials which will be allowed access to the target 
# (provided they can provide the correct password or other 

# authenticator). Entries in this list are of the form 

# "method/identifier", where the currently defined methods are 
# "Chap" and "srp", both of which take usernames as their 

# identifiers. 

# 

# 

# 

# 


This attribute contains security policy information. If this 
attribute is distributed via an Attribute Reply message, 
IPsec MUST be implemented. 


boot-list = string MO 
A list of iSCSI Initiator Names that can boot from this target. 
This list works precisely like the auth-name attribute. A name 
appearing in this list must either appear in the access-list, 
or the access-list must contain the initiator name "iscsi". 
Otherwise, an initiator will be unable to find its boot 
target. If boot-list contains the name "iscsi", any host can boot 
from it, but I am not sure if this is useful to anyone. If this 
attribute is not registered, this target is not "bootable". 


host will generally attempt to boot from LUN 0. 


It is quite possible that other attributes will need to be defined 
here for booting as well. 


This attribute contains security policy information. If this 
attribute is distributed via an Attribute Reply message, 


# 
# 
# 
# 
# 
# 
# 
# 
# 
# Note that the LUN the host boots from is not specified here; a 
# 
# 
# 
# 
# 
# 
# 
# IPsec MUST be implemented. 


5.3. iSCSI Storage Management Service Templates 


This template defines the service "Service:iscsi:sms". An entity 
supporting one or more iSCSI management service protocols may 
register itself with SLP as this service type. iSCSI clients and 
servers wishing to discover storage management services using SLP 
will usually search for them by the protocol(s) they support: 
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Service: service:iscsi:sms 
Scope: initiator-scope-list 
Query: (protocols=isns) 


Name of submitter: Mark Bakke 
Language of service template: en 
Security Considerations: see section 6. 


Template Text: 


template-type=iscsi:sms 
template-version=1.0 


template-description= 
This is a concrete service type. The iscsi:sms service type 
provides the capability for entities supporting iSCSI to discover 
appropriate management services. 


template-url-syntax= 


url-path = ; The URL of the management service [RFC2608]. 
protocols = string M 
# The list of protocols supported by this name service. This 
f list may be expanded in the future. There is no default. 
# 
# "isns" - This management service supports the use of the iSNS 
# protocol for access management, health monitoring, and 
# discovery management services. This protocol is defined 
# in [ISNS]. 
isns 
transports = string M L 
tcp 


# This is a list of transport protocols that the registered 
# entity supports. 
tcp, udp 


server-priority = integer 

The priority a client should give this server, when choosing 
between multiple servers with the same protocol type. 

When multiple servers are discovered for a given protocol type, 
this parameter indicates their relative precedence. Server 
precedence is protocol-specific; for some protocols, the primary 
server may have the highest server-priority value, while for 


Se Se SE SR SR FE 
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# others it may have the lowest. For example, with iSNS, the primary 
# server has the lowest value (value 0). 


6. Security Considerations 


The SLPv2 security model as specified in [RFC2608] does not provide 
confidentiality but does provide an authentication mechanism for UAs 
to ensure that service advertisements only come from trusted SAs, 
with the exception that it does not provide a mechanism to 
authenticate "zero-result responses". See [RFC3723] for a discussion 
of the SLPv2 [RFC2608] security model. 


Once a target or management server is discovered, authentication and 
authorization are handled by the iSCSI protocol, or by the management 
server’s protocol. It is the responsibility of the providers of 
these services to ensure that an inappropriately advertised or 
discovered service does not compromise their security. 


When no security is used for SLPv2, there is a risk of distribution 
of false discovery information. The primary countermeasure for this 
risk is authentication. When this risk is a significant concern, 
IPsec SAs and iSCSI in-band authentication SHOULD be used for iSCSI 
traffic subject to this risk to ensure that iSCSI traffic only flows 
between endpoints that have participated in IKE authentication and 
iSCSI in-band authentication. For example, if an attacker 
distributes discovery information falsely claiming that it is an 
iSCSI target, it will lack the secret information necessary to 
complete IKE authentication or iSCSI in-band authentication 
successfully and therefore will be prevented from falsely sending or 
receiving iSCSI traffic. 


A risk remains of a denial of service attack based on repeated use of 
false discovery information that will cause initiation of IKE 
negotiation. The countermeasures for this are administrative 
configuration of each iSCSI Target to limit the peers it is willing 
to communicate with (i.e., by IP address range and/or DNS domain), 
and maintenance of a negative authentication cache to avoid 
repeatedly contacting an iSCSI Target that fails to authenticate. 
These three measures (i.e., IP address range limits, DNS domain 
limits, negative authentication cache) MUST be implemented. 


The auth-name, auth-addr, auth-cred, and boot-list attributes 


comprise security policy information. When these are distributed, 
IPsec MUST be implemented. 
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6.1. Security Implementation 


Security for SLPv2 in an IP storage environment is specified in 


[RFC3723]. IPsec is mandatory-to-implement for IPS clients and 
servers. Thus, all IP storage clients, including those invoking SLP, 
can be assumed to support IPsec. SLP servers, however, cannot be 


assumed to implement IPsec, since there is no such requirement in 
standard SLP. In particular, SLP Directory Agents (DA) may be 
running on machines other than those running the IPS protocols. 


IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this 
includes ESP with a non-null transform to provide both authentication 
and confidentiality. 


When SLPv2 can be used to distribute auth-name, auth-addr, auth-cred, 
and boot-list information (see section 5.2 above), IPsec MUST be 
implemented, as these items are considered sensitive security policy 
information. If IPsec is not implemented, auth-name, auth-addr, 
auth-cred, and boot-list information MUST NOT be distributed via 
SLPv2 and MUST NOT be used if discovered via SLPv2. 


Because the IP storage services have their own authentication 
capabilities when located, SLPv2 authentication is OPTIONAL to 
implement and use (as discussed in more detail in [RFC3723]). 

7. IANA Considerations 
This document describes three SLP Templates. They have been reviewed 
and approved by the IESG and registered in the IANA’s "SVRLOC 
Templates" registry. This process is described in the IANA 
Considerations section of [RFC2609]. 


8. Summary 


This document describes how SLP can be used by iSCSI initiators to 


find iSCSI targets and storage management servers. Service type 
templates for iSCSI targets and storage management servers are 
presented. 


9. Normative References 


[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 
"Service Location Protocol, Version 2", RFC 2608, June 
1999, 

[RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service 


Templates and Service: Schemes", RFC 2609, June 1999. 


Bakke & Hufferd Standards Track [Page 19] 


RFC 4018 


10. 


Bakke & Hufferd 


[RFC2119] 


[RFC3491] 


[RFC3513] 


[RFC3720] 


[RFC3722] 


[RFC3723] 


iSCSI and SLPv2 April 2005 


Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 


Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 
Profile for Internationalized Domain Names (IDN)", RFC 
3491, March 2003. 


Hinden, R. and S. Deering, "Internet Protocol Version 6 
(IPv6) Addressing Architecture", RFC 3513, April 2003. 


Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., 
and E. Zeidner, "Internet Small Computer Systems 
Interface (iSCSI)", RFC 3720, April 2004. 


Bakke, M., "String Profile for Internet Small Computer 
Systems Interface (iSCSI) Names", RFC 3722, April 2004. 


Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. 
Travostino, "Securing Block Storage Protocols over IP", 
RFC 3723, April 2004. 


Informative References 


[RFC2614] 


[SAM2] 


[RFC3721] 


[ISNS] 


r 


BOOT] 


[RFC3105] 


Kempf, J. and E. Guttman, "An API for Service Location", 
RFC 2614, June 1999. 


ANSI T10. "SCSI Architectural Model 2", March 2000. 


Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. 
Krueger, "Internet Small Computer Systems Interface 
(iSCSI) Naming and Discovery", RFC 3721, April 2004. 


Tseng, J., Gibbons, K., Travostino, F., Du Laney, C. and 
Jx Souza, "Internet Storage Name Service", Work in 
Progress, February 2004. 


Sarkar, P., Missimer, D. and C. Sapuntzakis, "A Standard 
for Bootstrapping Clients using the iSCSI Protocol", Work 


in Progress, March 2004. 


Kempf, J. and G. Montenegro, "Finding an RSIP Server with 
SLP", RFC 3105, October 2001. 


Standards Track [Page 20] 


RFC 4018 iSCSI and SLPv2 April 2005 


11. Acknowledgements 


This document was produced by the iSCSI Naming and Discovery team, 
including Joe Czap, Jim Hafner, John Hufferd, and Kaladhar Voruganti 
(IBM), Howard Hall (Pirus), Jack Harwood (EMC), Yaron Klein (Sanrad), 
Marjorie Krueger (HP), Lawrence Lamers (San Valley), Todd Sperry 
(Adaptec), and Joshua Tseng (Nishan). Thanks also to Julian Satran 
(IBM) for suggesting the use of SLP for iSCSI discovery, and to Matt 
Peterson (Caldera) and James Kempf (Sun) for reviewing the document 
from an SLP perspective. 


Bakke & Hufferd Standards Track [Page 21] 


RFC 4018 iSCSI and SLPv2 April 2005 


Authors’ Addresses 


Mark Bakke 

Cisco Systems, Inc. 

7900 International Drive, Suite 400 
Bloomington, MN 

USA 55425 


EMail: mbakke@cisco.com 


Kaladhar Voruganti 

IBM Almaden Research Center 
650 Harry Road 

San Jose, CA 95120 


EMail: kaladhar@us.ibm.com 


John L. Hufferd 

IBM Storage Systems Group 
5600 Cottle Road 

San Jose, CA 95193 


Phone: +1 408 997-6136 
EMail: jlhufferd@comcast.net 


Marjorie Krueger 
Hewlett-Packard Corporation 
8000 Foothills Blvd 
Roseville, CA 95747-5668, USA 


Phone: +1 916 785-2656 
EMail: marjorie_krueger@hp.com 


Todd Sperry 

Adaptec, Inc. 

691 South Milpitas Boulevard 
Milpitas, Ca. 95035 


Phone: +1 408 957-4980 
EMail: todd_sperry@adaptec.com 


Bakke & Hufferd Standards Track [Page 22] 


RFC 4018 iSCSI and SLPv2 April 2005 


Full Copyright Statement 
Copyright (C) The Internet Society (2005). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at ietf- 
ipr@ietf.org. 


Acknowledgement 


Funding for the RFC Editor function is currently provided by the 
Internet Society. 


Bakke & Hufferd Standards Track [Page 23] 


